Efficiently transmitting RTP Protocol in a network that guarantees in order delivery of packets

ABSTRACT

A method and computer program product for providing RTP suppression across a DOCSIS network. An index number and a set of rules are sent to a receiver. The index number indicates the type of header suppression technique (i.e., RTP header suppression) to be performed, and the set of rules define how to recreate the RTP packets on the receiving end. At least one complete RTP packet is transmitted upstream for enabling a receiver to learn the RTP header. Subsequent RTP packets are transmitted upstream for reconstruction at the receiving end. The subsequent RTP packets are comprised of delta values representing fields that dynamically change from packet to packet in an RTP header.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.09/973,872, filed Oct. 11, 2001, now U.S. Pat. No. 7,130,314, whichclaims priority to the following provisional applications:

Provisional U.S. Patent Application Ser. No. 60/239,525, entitled “Usingthe TDMA Characteristics of a DOCSIS Cable Modem Network to SupportExtended Protocols,” filed Oct. 11, 2000, by Bunn et al., (stillpending)(incorporated by reference in its entirety herein).

Provisional U.S. patent application Ser. No. 60/239,526, entitled“Dynamic Delta Encoding for Cable Modem Header Suppression,” filed Oct.11, 2000 by Bunn et al., (still pending)(incorporated by reference inits entirety herein).

Provisional U.S. patent application Ser. No. 60/239,524, entitled“Dynamically Mixing Protocol-Specific Header Suppression Techniques toMaximize Bandwidth Utilization in a DOCSIS Network,” filed Oct. 11, 2000by Bunn et al., (still pending)(incorporated by reference in itsentirety herein).

Provisional U.S. Patent Application Ser. No. 60/239,530, entitled“Efficiently Transmitting RTP Protocol in a Network that Guarantees InOrder Delivery of Packets,” filed Oct. 11, 2000 by Bunn et al., (stillpending)(incorporated by reference in its entirety herein).

Provisional U.S. Patent Application Ser. No. 60/239,527, entitled“Packet PDU Data Compression within a DOCSIS Network,” filed Oct. 11,2000, by Bunn et al., (still pending)(incorporated by reference in itsentirety herein).

Provisional U.S. Patent Application Ser. No. 60/240,550, entitled “CableModem System,” filed Oct. 13, 2000, by Bunn et al., (stillpending)(incorporated by reference in its entirety herein).

This application is related to the following non-provisionalapplications, all having the same filing date as the presentapplication:

“Cable Modem System and Method for Supporting Extended Protocols,” U.S.Pat. Ser. No. 09/973,875, by Bunn et aL., filed concurrently herewithand incorporated by reference herein in its entirety.

“Cable Modem System and Method for Dynamically Mixing Protocol SpecificHeader Suppression Techniques,” U.S. Pat. Ser. No. 09/973,781, by Bunnet al., filed concurrently herewith and incorporated by reference hereinin its entirety.

“Dynamic Delta Encoding for Cable Modem Header Suppression,” U.S. Pat.Ser. No. 09/973,871, by Bunn et al., filed concurrently herewith andincorporated by reference herein in its entirety.

“Cable Modem System and Method for Supporting Packet PDU DataCompression,” U.S. Pat. Ser. No. 09/973,783, by Bunn et al., filedconcurrently herewith and incorporated by reference herein in itsentirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is generally related to communication systems.More particularly, the present invention is related to a cable modemsystem and a method and computer program product for providing Real TimeProtocol header suppression across a DOCSIS network.

2. Background Art

Conventional cable modem systems utilize DOCSIS (Data Over Cable SystemInterface Specification)—compliant equipment and protocols to transferdata between one or more cable modems (CM) and a cable modem terminationsystem (CMTS). DOCSIS generally refers to a group of specifications thatdefine industry standards for cable headend and cable modem equipment.In part, DOCSIS sets forth requirements and objectives for variousaspects of cable modem systems including operations support systems,management, data interfaces, as well as network layer, data link layer,and physical layer transport for cable modem systems.

Real-time Transport Protocol (RTP) is a protocol for deliveringpacketized audio and video traffic over an Internet Protocol network.RTP provides end-to-end network transport functions for applicationswith real-time requirements. Such applications may include audio, video,or simulation data over multicast or unicast network services. RTP isalso used to send VOIP (voice over IP) phone calls.

An increasing number of applications are utilizing RTP to deliver voiceand multimedia data streams. The data portion of an RTP packet is oftensmall in comparison to the protocol overhead required to send theinformation. Current techniques for delivering RTP packets waste networkbandwidth by sending redundant information. Also, current techniques donot allow for the suppression of changing RTP fields in a data stream.

DOCSIS 1.1 provides a technique for the suppression of redundantinformation called “payload header suppression” (PHS). PHS enables thesuppression of unchanging bytes in an individual Service Identifier(SID) (i.e., data stream). Thus, DOCSIS PHS provides byte orientedsuppression. Byte oriented suppression is not as efficient as a fieldoriented protocol header suppression scheme. Another downside to PHS isits inability to suppress dynamically changing fields in a data stream.

What is needed is a system and method for in order delivery oftransmitted RTP packets that eliminates the transmission of redundantpatterns. What is also needed is a system and method for in orderdelivery of transmitted RTP packets that provides a field orientedprotocol header suppression scheme. What is further needed is a systemand method for in order delivery of transmitted RTP packets thatsuppresses dynamically changing fields in a data stream.

BRIEF SUMMARY OF THE INVENTION

The present invention satisfies the above-mentioned needs by providing amethod and computer program product for RTP header suppression thatsuppresses dynamically changing fields in an RTP data stream. Thepresent invention performs RTP header suppression over a DOCSIS cablemodem network, and thus, guarantees in-order delivery of the transmittedpackets. The suppression technique of the present invention alsoeliminates the transmission of redundant patterns that occur from packetto packet.

According to a method of the present invention, an index number and aset of rules are sent to a receiver. The index number indicates the typeof header suppression technique (i.e., RTP header suppression) to beperformed, and the set of rules define how to recreate the RTP packetson the receiving end. At least one complete RTP packet is transmittedupstream for enabling a receiver to learn the RTP header. Subsequent RTPpackets are transmitted upstream for reconstruction at the receivingend. The subsequent RTP packets are comprised of delta valuesrepresenting fields that dynamically change from packet to packet. Thepresent invention eliminates the need to transmit redundant patternsacross a network while suppressing changing RTP fields in a data stream.The invention increases the bandwidth capacity of high-speed DOCSIScable modem networks by employing field level encoding rather thansimple byte substitution. Further embodiments, features, and advantagesof the present invention, as well as the structure and operation of thevarious embodiments of the present invention, are described in detailbelow with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated herein and form partof the specification, illustrate the present invention and, togetherwith the description, further serve to explain the principles of theinvention and to enable a person skilled in the pertinent art to makeand use the invention.

FIG. 1 is a high level block diagram of a cable modem system inaccordance with embodiments of the present invention.

FIG. 2 is a schematic block diagram of a cable modem termination system(CMTS) in accordance with embodiments of the present invention.

FIG. 3 is a schematic block diagram of a cable modem in accordance withembodiments of the present invention.

FIG. 4 is a flowchart of a method for supporting extended protocols in acable modem system in accordance with embodiments of the presentinvention.

FIG. 5 is a flowchart of a method for supporting extended protocols in acable modem system in accordance with embodiments of the presentinvention.

FIG. 6A is a block diagram of an uncompressed packet typically receivedby a cable modem in accordance with embodiments of the presentinvention.

FIG. 6B is a block diagram of a packet compressed by a cable modem inaccordance with embodiments of the present invention.

FIG. 6C is a block diagram of a single SID containing multiple packetscompressed by a cable modem using different packet header suppressiontechniques in accordance with embodiments of the present invention.

FIG. 7 is a flowchart of a method for compressing packets usingdifferent packet header suppression techniques in accordance withembodiments of the present invention.

FIG. 8 is a flowchart of a method for expanding packets compressed usingdifferent packet header suppression techniques in accordance withembodiments of the present invention.

FIG. 9A is a diagram of an exemplary 802.3/IP/UDP/RTP header.

FIG. 9B is a diagram of an RTP protocol packet.

FIG. 10 is a diagram illustrating a control value byte used during theoperation of a RTP header suppression technique.

FIG. 11 is a high level flow diagram illustrating a method for RTPheader suppression.

FIG. 12A is a flow diagram illustrating a method for suppressing an RTPheader using an RTP header suppression technique according to anembodiment of the present invention.

FIG. 12B is a flow diagram illustrating a method for setting theincrement of an IP packet ID field in an RTP header according to anembodiment of the present invention.

FIG. 13 is a flow diagram illustrating a method for reconstructing anRTP header using an RTP header suppression technique according to anembodiment of the present invention.

FIG. 14A is a diagram illustrating an exemplary 802.3/IP/TCP header.

FIG. 14B is a diagram illustrating a TCP Protocol packet.

FIG. 15 is a diagram illustrating a TCP Protocol packet highlightingfields that may change from packet to packet.

FIG. 16A is a high level diagram illustrating a method for a deltaencoded header suppression technique according to an embodiment of thepresent invention.

FIG. 16B is a high level diagram illustrating a method for a deltaencoded header reconstruction technique according to an embodiment ofthe present invention.

FIG. 17 is a diagram illustrating a change byte according to anembodiment of the present invention.

FIG. 18 is a diagram illustrating a final encoded data stream accordingto an embodiment of the present invention.

FIG. 19 is a diagram illustrating the transmit order of data for TCPheader suppression for a non-learning state according to an embodimentof the present invention.

FIG. 20 is a diagram illustrating the transmit order of data for TCPheader suppression for a learn state according to an embodiment of thepresent invention.

FIG. 21 is a flow diagram illustrating a method for TCP headersuppression according to an embodiment of the present invention.

FIGS. 22A and 22B are a flow diagram illustrating a method for TCPheader reconstruction according to an embodiment of the presentinvention.

FIG. 23 is a diagram illustrating an exemplary computer system.

The features, objects, and advantages of the present invention willbecome more apparent from the detailed description set forth below whentaken in conjunction with the drawings in which like referencecharacters identify corresponding elements throughout. In the drawings,like reference numbers generally indicate identical, functionallysimilar, and/or structurally similar elements. The drawings in which anelement first appears is indicated by the leftmost digit(s) in thecorresponding reference number.

DETAILED DESCRIPTION OF THE INVENTION Table of Contents

-   A. Cable Modem System in Accordance with Embodiments of the Present    Invention-   B. Example Cable Modem System Components in Accordance with    Embodiments of the Present Invention-   C. Supporting Extended Data Transfer Protocols in Accordance with    Embodiments of the Present Invention-   1. Packet Header Suppression-   2. Packet Header Expansion-   3. RTP Header Suppression-   4. Dynamic Delta Encoding Scheme-   D. Environment-   E. Conclusion

While the present invention is described herein with reference toillustrative embodiments for particular applications, it should beunderstood that the invention is not limited thereto. Those skilled inthe art with access to the teachings provided herein will recognizeadditional modifications, applications, and embodiments within the scopethereof and additional fields in which the present invention would be ofsignificant utility.

A. Cable Modem System in accordance with Embodiments of the PresentInvention

FIG. 1 is a high level block diagram of an example cable modem system100 in accordance with embodiments of the present invention. The cablemodem system 100 enables voice communications, video and data servicesbased on a bi-directional transfer of packet-based traffic, such asInternet protocol (IP) traffic, between a cable system headend 102 and aplurality of cable modems over a hybrid fiber-coaxial (HFC) cablenetwork 110. In the example cable modem system 100, only two cablemodems 106 and 108 are shown for clarity. In general, any number ofcable modems may be included in the cable modem system of the presentinvention.

The cable headend 102 is comprised of at least one cable modemtermination system (CMTS) 104. The CMTS 104 is the portion of the cableheadend 102 that manages the upstream and downstream transfer of databetween the cable headend 102 and the cable modems 106 and 108, whichare located at the customer premises. The CMTS 104 broadcastsinformation downstream to the cable modems 106 and 108 as a continuoustransmitted signal in accordance with a time division multiplexing (TDM)technique. Additionally, the CMTS 104 controls the upstream transmissionof data from the cable modems 106 and 108 to itself by assigning to eachcable modem 106 and 108 short grants of time within which to transferdata. In accordance with this time domain multiple access (TDMA)technique, each cable modem 106 and 108 may only send informationupstream as short burst signals during a transmission opportunityallocated to it by the CMTS 104.

As shown in FIG. 1, the CMTS 102 further serves as an interface betweenthe HFC network 110 and a packet-switched network 112, transferring IPpackets received from the cable modems 106 and 108 to thepacket-switched network 112 and transferring IP packets received fromthe packet-switched network 112 to the cable modems 106 and 108 whenappropriate. In embodiments, the packet-switched network 112 comprisesthe Internet.

In addition to the CMTS 104, the cable headend 102 may also include oneor more Internet routers to facilitate the connection between the CMTS104 and the packet-switched network 112, as well as one or more serversfor performing necessary network management tasks.

The HFC network 110 provides a point-to-multipoint topology for thehigh-speed, reliable, and secure transport of data between the cableheadend 102 and the cable modems 106 and 108 at the customer premises.As will be appreciated by persons skilled in the relevant art(s), theHFC network 110 may comprise coaxial cable, fiberoptic cable, or acombination of coaxial cable and fiberoptic cable linked via one or morefiber nodes.

Each of the cable modems 106 and 108 operates as an interface betweenthe HFC network 110 and at least one attached user device. Inparticular, the cable modems 106 and 108 perform the functions necessaryto convert downstream signals received over the HFC network 110 into IPdata packets for receipt by an attached user device. Additionally, thecable modems 106 and 108 perform the finctions necessary to convert IPdata packets received from the attached user device into upstream burstsignals suitable for transfer over the HFC network 110. In the examplecable modem system 100, each cable modem 106 and 108 is shown supportingonly a single user device for clarity. In general, each cable modem 106and 108 is capable of supporting a plurality of user devices forcommunication over the cable modem system 100. User devices may includepersonal computers, data terminal equipment, telephony devices,broadband media players, network-controlled appliances, or any otherdevice capable of transmitting or receiving data over a packet-switchednetwork.

In the example cable modem system 100, cable modem 106 represents aconventional DOCSIS-compliant cable modem. In other words, cable modem106 transmits data packets to the CMTS 104 in formats that adhere to theprotocols set forth in the DOCSIS specification. Cable modem 108 islikewise capable of transmitting data packets to the CMTS 104 instandard DOCSIS formats. However, in accordance with embodiments of thepresent invention, the cable modem 108 is also configured to transmitdata packets to the CMTS 104 using proprietary protocols that extendbeyond the DOCSIS specification. Nevertheless, cable modem 108 is fullyinteroperable with the DOCSIS-compliant cable modems, such as cablemodem 106, and with DOCSIS-compliant CMTS equipment. The manner in whichcable modem 108 operates to transfer data will be described in furtherdetail herein.

Furthermore, in the example cable modem system 100, the CMTS 104operates to receive and process data packets transmitted to it inaccordance with the protocols set forth in the DOCSIS specification.However, in accordance with embodiments of the present invention, theCMTS 104 can also operate to receive and process data packets that areformatted using proprietary protocols that extend beyond those providedby the DOCSIS specification, such as data packets transmitted by thecable modem 108. The manner in which the CMTS 104 operates to receiveand process data will also be described in further detail herein.

B. Example Cable Modem System Components in Accordance with Embodimentsof the Present Invention

FIG. 2 depicts a schematic block diagram of an implementation of theCMTS 104 of cable modem system 100, which is presented by way ofexample, and is not intended to limit the present invention. The CMTS104 is configured to receive and transmit signals to and from the HFCnetwork 110, a portion of which is represented by the optical fiber 202of FIG. 2. Accordingly, the CMTS 104 will be described in terms of areceiver portion and a transmitter portion.

The receiver portion includes an optical-to-coax stage 204, an RF input206, a splitter 214, and a plurality of burst receivers 216. Receptionbegins with the receipt of upstream burst signals originating from oneor more cable modems by the optical-to-coax stage 204 via the opticalfiber 202. The optical-to-coax stage 204 routes the received burstsignals to the radio frequency (RF) input 206 via coaxial cable 208. Inembodiments, these upstream burst signals having spectralcharacteristics within the frequency range of roughly 5-42 MHz.

The received signals are provided by the RF input 206 to the splitter214 of the CMTS 104, which separates the RF input signals into Nseparate channels. Each of the N separate channels is then provided to aseparate burst receiver 216 which operates to demodulate the receivedsignals on each channel in accordance with either a Quadrature PhaseShift Key (QPSK) or 16 Quadrature Amplitude Modulation (QAM) techniqueto recover the underlying information signals. Each burst receiver 216also converts the underlying information signals from an analog form todigital form. This digital data is subsequently provided to the headendmedia access control (MAC) 218.

The headend MAC 218 operates to process the digital data in accordancewith the DOCSIS specification and, when appropriate, in accordance withproprietary protocols that extend beyond the DOCSIS specification, aswill be described in further detail herein. The functions of the headendMAC 218 may be implemented in hardware or in software. In the exampleimplementation of FIG. 2, the functions of the headend MAC 218 areimplemented both in hardware and software. Software functions of theheadend MAC 218 may be stored in either the random access memory (RAM)220 or the read-only memory (ROM) 218 and executed by the CPU 222. Theheadend MAC is in electrical communication with these elements via abackplane interface 220 and a shared communications medium 232. Inembodiments, the shared communications medium 232 may comprise acomputer bus or a multiple access data network.

The headend MAC 218 is also in electrical communication with theEthernet interface 224 via both the backplane interface 220 and theshared communications medium 232. When appropriate, Ethernet packetsrecovered by the headend MAC 218 are transferred to the Ethernetinterface 224 for delivery to the packet-switched network 112 via arouter.

The transmitter portion of the CMTS 104 includes a downstream modulator226, a surface acoustic wave (SAW) filter 228, an amplifier 230, anintermediate frequency (IF) output 212, a radio frequency (RF)upconverter 210 and the optical-to-coax stage 204. Transmission beginswith the generation of a digital broadcast signal by the headend. MAC218. The digital broadcast signal may include data originally receivedfrom the packet-switched network 112 via the Ethernet interface 224. Theheadend MAC 218 outputs the digital broadcast signal to the downstreammodulator 226 which converts it into an analog form and modulates itonto a carrier signal in accordance with either a 64-QAM or 256-QAMtechnique.

The modulated carrier signal output by the downstream modulator 256 isinput to the SAW filter 228 which passes only spectral components of thesignal that are within a desired bandwidth. The filtered signal is thenoutput to an amplifier 230 which amplifies it and outputs it to the IFoutput 212. The IF output 212 routes the signal to the RF upconverter210, which upconverts the signal. In embodiments, the upconverted signalhas spectral characteristics in the frequency range of approximately54-860 MHz. The upconverted signal is then output to the optical-to-coaxstage 204 over the coaxial cable 208. The optical-to-coax stage 204broadcasts the signal via the optical fiber 202 of the HFC network 110.

FIG. 3 depicts a schematic block diagram of an implementation of thecable modem 108 of cable modem system 100, which is presented by way ofexample, and is not intended to limit the present invention. The cablemodem 108 is configured to receive and transmit signals to and from theHFC network 110 via the coaxial connector 332 of FIG. 3. Accordingly,the cable modem 108 will be described in terms of a receiver portion anda transmitter portion.

The receiver portion includes a diplex filter 302, an RF tuner 304, aSAW filter 306, and amplifier 308, and a downstream receiver 310.Reception begins with the receipt of a downstream signal originatingfrom the CMTS 104 by the diplex filter 302.

The diplex filter 302 operates to isolate the downstream signal androute it to the RF tuner 304. In embodiments, the downstream signal hasspectral characteristics in the frequency range of roughly 54-860 MHz.The RF tuner 304 downconverts the signal and outputs it to the SAWfilter 306, which passes only spectral components of the downconvertedsignal that are within a desired bandwidth. The filtered signal isoutput to the amplifier 308 which amplifies it and passes it to thedownstream receiver 310. Automatic gain controls are provided from thedownstream receiver 310 to the RF tuner 304.

The downstream receiver 310 demodulates the amplified signal inaccordance with either a 64-QAM or 256-QAM technique to recover theunderlying information signal. The downstream receiver 310 also convertsthe underlying information signal from an analog form to digital form.This digital data is subsequently provided to the media access control(MAC) 314.

The MAC 314 processes the digital data, which may include, for example,Ethernet packets for transfer to an attached user device. The functionsof the MAC 314 may be implemented in hardware or in software. In theexample implementation of FIG. 3, the finctions of the MAC 314 areimplemented in both hardware and software. Software functions of the MAC314 may be stored in either the RAM 322 or the ROM 324 and executed bythe CPU 320. The MAC 314 is in electrical communication with theseelements via a shared communications medium 316. In embodiments, theshared communications medium may comprise a computer bus or a multipleaccess data network.

The MAC 314 is also in electrical communication with the Ethernetinterface 318 via the shared communications medium 316. Whenappropriate, Ethernet packets recovered by the MAC 314 are transferredto the Ethernet interface 318 for transfer to an attached user device.

The transmitter portion of the cable modem 108 includes an upstreamburst modulator 326, a low pass filter 328, a power amplifier 330, andthe diplex filter 302. Transmission begins with the construction of adata packet by the MAC 314. The data packet may include data originallyreceived from an attached user device via the Ethernet interface 318. Inaccordance with embodiments of the present invention, the MAC 314 mayfornat the data packet in compliance with the protocols set forth in theDOCSIS specification or, when appropriate, may format the data packet incompliance with a proprietary protocol that extends beyond those setforth in the DOCSIS specification, as will be described in furtherdetail herein. The MAC 314 outputs the data packet to the upstream burstmodulator 326 which converts it into analog form and modulates it onto acarrier signal in accordance with either a QPSK or 16-QAM technique.

The upstream burst modulator 326 outputs the modulated carrier signal tothe low pass filter 328 which passes signals with spectralcharacteristics in a desired bandwidth. In embodiments, the desiredbandwidth is within the frequency range of approximately 5-42 MHz. Thefiltered signals are then introduced to the power amplifier 330 whichamplifies the signal and provides it to the diplex filter 302. The gainin the power amplifier 330 is regulated by the burst modulator 326. Thediplex filter 302 isolates the amplified signal and transmits itupstream over the HFC network 110 during a scheduled burst opportunity.

C. Supporting Extended Data Transfer Protocols in Accordance withEmbodiments of the Present Invention

As noted above, in accordance with embodiments of the present invention,the cable modem 108 and the CMTS 104 send and receive data,respectively, in proprietary formats that extend beyond standard DOCSISprotocols. For example, in embodiments, the cable modem 108 modifiesdata packets in accordance with a proprietary header suppression schemefor transmission to the CMTS 104, and, upon receipt of the modified datapackets, the CMTS 104 reconstructs them in accordance with the sameproprietary header compression scheme.

In further accordance with embodiments of the present invention, thecable modem 108 is nevertheless interoperable with conventionalDOCSIS-compliant CMTS equipment that, unlike the CMTS 104, do notprovide support for extended protocols. The cable modem 108 achievesthis end by determining whether it is communicating with a CMTS thatsupports extended protocols, such as the CMTS 104, or with a CMTS thatdoes not. If the CMTS does not support extended protocols, the cablemodem 108 transfers data formatted in accordance with standard DOCSISprotocols rather than extended protocols.

FIG. 4 depicts a flowchart 400 of a method for supporting extendedprotocols in a cable modem system in accordance with embodiments of thepresent invention that explains this process in more detail. Theinvention, however, is not limited to the description provided by theflowchart 400. Rather, it will be apparent to persons skilled in therelevant art(s) from the teachings provided herein that other functionalflows are within the scope and spirit of the present invention. Theflowchart 400 will be described with continued reference to the exampleCMTS 104 and cable modem 108 of the cable modem system 100, as well asin reference to the example hardware implementation of the cable modem108 of FIG. 3.

In step 402, the cable modem 108 sends a registration message to theCMTS 104 designating support for an extended protocol. With regard tothe example implementation of cable modem 108 described in reference toFIG. 3, the MAC 314 constructs this registration message, as well as allother MAC maintenance messages issued by the cable modem 108.

In embodiments, the cable modem 108 sends this registration message aspart of an exchange of registration messages that must occur between acable modem and a CMTS when the cable modem first appears on the HFCnetwork. In accordance with the DOCSIS specification, this exchange ofregistration messages generally includes the sending of a RegistrationRequest (REG-REQ) message from the cable modem to the CMTS and thesending of a Registration Response (REG-RSP) message from the CMTS tothe cable modem in response to the received REG-REQ message. Thisregistration protocol is well-known in the art.

In embodiments, the cable modem 108 notifies the CMTS 104 that itsupports an extended protocol by placing an extended protocol supportdescriptor in a vendor-specific information field of the REG-REQ messagethat it sends to the CMTS104. Conversely, in such embodiments, theabsence of an extended protocol support descriptor in a vendor-specificinformation field of the REG-REQ message designates that a cable modemsupports only standard DOCSIS protocols.

At step 404, the cable modem 108 receives a response to the registrationmessage from the CMTS 104 that indicates whether or not the CMTS 104supports the extended protocol. Since the CMTS 104 of the exemplarycable modem system 100 supports the same extended protocol as cablemodem 108, as discussed above, the response to the registration messagewill indicate that the extended protocol is supported. However, if theCMTS 104 did not support the extended protocol (for example, if it was aconventional DOCSIS-compliant CMTS), then the response to theregistration message would include an indication that the CMTS 104failed to recognize the extended protocol. For example, in embodimentswhere the registration message comprises a REG-REQ message that includesan extended protocol support descriptor in a vendor-specific informationfield, the response may be a REG-RSP message that indicates that theCMTS 104 failed to recognize extended protocol support descriptor.

If the response to the registration message indicates that the extendedprotocol is supported by the CMTS, then the cable modem 108 will formatdata packets for transmission to the CMTS in accordance with theextended protocol, as shown by steps 406 and 408. If, on the other hand,the response to the registration message indicates that the CMTS doesnot support the extended protocol, then the cable modem 108 will formatdata packets for transmission to the CMTS in accordance with standardDOCSIS protocols, as shown by steps 406 and 410. As discussed above inregard to the example implementation of cable modem 108 depicted in FIG.3, the MAC 314 is responsible for formatting data packets fortransmission to the CMTS.

In alternate embodiments of the present invention, a privatecommunications channel may be utilized to implement steps 402 and 404 offlowchart 400 instead of the standard DOCSIS REG-REQ, REG-RSP protocoldescribed above. For example, in such an embodiment, the CMTS 104 sendsa unicast UDP message to the cable modem 108 following successful cablemodem registration that indicates that the CMTS 104 is capable ofsupporting extended protocols (step not shown in FIG. 4). If the cablemodem 108 supports an extended protocol, it responds to the UDP messageby sending a UDP response indicating which extended protocol itsupports. In accordance with this technique, the registration message ofstep 402 comprises the UDP response from the cable modem 108. Inembodiments, the UDP response also indicates the specific degree towhich the cable modem 108 is capable of supporting the extendedprotocol.

If the cable modem does not support an extended protocol, it sends noresponse to the UDP message. In embodiments, the CMTS 104 re-transmitsthe UDP message a predetermined number of times and, if no response isreceived from the cable modem after the predetermined number ofre-transmissions, the CMTS 104 determines that the cable modem does notsupport any extended protocols. However, if the CMTS 104 receives anappropriate UDP response from the cable modem 108, it captures theextended protocol capabilities of the cable modem 108 and responds witha second UDP message indicating whether or not it supports the specificextended protocol supported by the cable modem 108. In accordance withthis technique, the response to the registration message of step 404comprises the second UDP message from the CMTS 104.

The method described in flowchart 400 ensures interoperability between acable modem that supports an extended protocol in accordance withembodiments of the present invention and CMTS equipment that does notsupport the same protocol. Similarly, a CMTS that supports an extendedprotocol in accordance with embodiments of the present invention, suchas CMTS 104, is interoperable with a cable modem that does not supportthe same extended protocol. For example, the CMTS 104 is interoperablewith conventional DOCSIS-compliant cable modems that do not supportextended protocols, such as cable modem 106. The CMTS 104 achieves thisend by determining whether a received packet has been sent from aconventional DOCSIS-compliant cable modem, such as the cable modem 106,or from a cable modem capable of transmitting data using extendedprotocols, such as the cable modem 108, and processing the packetaccordingly.

FIG. 5 depicts a flowchart 500 of a method for supporting extendedprotocols in a cable modem system in accordance with embodiments of thepresent invention that explains this process in more detail. Theinvention, however, is not limited to the description provided by theflowchart 500. Rather, it will be apparent to persons skilled in therelevant art(s) from the teachings provided herein that other functionalflows are within the scope and spirit of the present invention. Theflowchart 500 will be described with continued reference to the exampleCMTS 104 and cable modems 106 an 108 of the cable modem system 100, aswell as in reference to the example hardware implementation of the CMTS104 of FIG. 2.

At step 502, the CMTS 104 receives a registration message from a cablemodem designating a data transfer protocol supported by the cable modem.With regard to the example cable modem system 100 of FIG. 1, theregistration message may be from cable modem 106, in which case themessage designates data transfer in accordance with standard DOCSISprotocols, or the registration message may be from cable modem 108, inwhich case the message designates data transfer in accordance with anextended protocol. In embodiments, the registration message is a DOCSISREG-REQ message, and the presence of an extended protocol descriptor ina vendor-specific field of the REG-REQ message designates data transferin accordance with an extended protocol, while the absence of theextended protocol descriptor designates data transfer in accordance withstandard DOCSIS protocols.

At step 504, the CMTS 104 assigns a unique cable modem ID to the cablemodem and transmits the cable modem ID to the cable modem. Inembodiments, the cable modem ID comprises the DOCSIS primary Service ID(SID) that is assigned by the CMTS and transmitted to the cable modem aspart of the DOCSIS REG-RSP message. With regard to the exampleimplementation of CMTS 104 described in reference to FIG. 2, the headendMAC 218 is responsible for assigning a unique cable modem ID to thecable modem.

At step 506, the CMTS 104 creates an association in memory between thecable modem ID and a protocol indicator that indicates the data transferprotocol supported by the cable modem. With regard to the exampleimplementation of CMTS 104 described in reference to FIG. 2, this taskis carried out by the headend MAC 218 which stores the cable modem IDand protocol indicator as associated values in either ROM 218 or RAM220. In embodiments, the CMTS 104 stores the cable modem ID and protocolindicator as associated values in a look-up table.

At step 508, the CMTS 104 receives a request for transmissionopportunity from a cable modem which includes the cable modem IDassociated with the cable modem. In embodiments, the request is receivedin a request contention area defined by a DOCSIS allocation MAP. Theallocation MAP is a varying-length MAC Management message transmitted bythe CMTS on the downstream channel that describes, for some timeinterval, the uses to which the upstream bandwidth must be put. Theallocation MAP allocates bandwidth in terms of basic time units calledmini-slots. A given allocation MAP may describe some mini-slots as agrant for a particular cable modem to transmit data in and othermini-slots as available for contention transmission by multiple cablemodems. The DOCSIS allocation MAP is described in the DOCSISspecification and is well-known in the art.

At step 510, the CMTS 104 allocates a transmission opportunity to thecable modem in response to the request for transmission opportunity. Inembodiments, the CMTS 104 allocates a transmission opportunity to thecable modem by assigning a number of mini-slots in a DOCSIS allocationMAP to the cable modem for transferring data upstream, in accordancewith the DOCSIS specification. With regard to the example implementationof CMTS 104 described in reference to FIG. 2, the construction of a MAPallocation message is executed by the headend MAC 218.

At step 512, the CMTS 104 uses the cable modem ID from the request fortransmission opportunity to access the protocol indicator associatedwith the cable modem ID, which was stored in memory at prior step 506.In embodiments, the CMTS 104 consults a look-up table that maps thecable modem ID to the protocol indicator. In regard to the exampleimplementation of CMTS 104 described in reference to FIG. 2, this stepis performed by the headend MAC 218.

At step 514, the CMTS 104 processes data transmitted by the cable modemduring the allocated transmission opportunity in accordance with thedata transfer protocol indicated by the indicator. For example, if theindicator indicates that an extended protocol is supported, as in thecase of cable modem 108, then the CMTS 104 will process the data packetit expects to receive from the cable modem in accordance with anextended protocol. If no support for an extended protocol is indicated,as in the case of cable modem 106, then the CMTS 104 will process thedata packet it expects to receive from the cable modem in accordancewith standard DOCSIS procotols. In regard to the example implementationof CMTS 104 described in reference to FIG. 2, the processing of datapackets is performed by the headend MAC 218.

Thus, in accordance with embodiments of the present invention, the CMTS104 acquires and stores information during cable modem registrationabout the capabilities of the cable modems to which it will communicate.When the CMTS 104 subsequently allocates upstream bandwidth to a cablemodem, it accesses the stored information to determine how to processthe data it expects to receive from the cable modem. This technique isfacilitated by the TDMA aspects of a cable modem system, which requiresthe CMTS to be aware of which cable modem it is receiving data from atany given time.

This technique is advantageous because it permits the use of protocolsthat extend beyond DOCSIS, while ensuring interoperability by adheringto standard DOCSIS registration, request and grant protocols.

1. Packet Header Suppression

FIGS. 6A-8 are useful for explaining a manner in which packets arecompressed by cable modem 108 and expanded by the CMTS 104 in accordancewith embodiments of the present invention.

FIG. 6A represents a data packet 605 generated by a user device fortransmission over the HFC network 110. The data packet 605 includes aMAC header 607, an IP header 609, a UDP header 611, an RTP header 613,and a Payload 615. In this example, the MAC header 607 comprises 14bytes, the IP header 609 comprises 20 bytes, the UDP header 611comprises 12 bytes, the RTP header 613 comprises 8 bytes, and thePayload 615 comprises anywhere from 1 to N bytes, depending on the typeof data being sent.

In accordance with the present invention, the data packet 605 can begenerated by an application program running on the user device 116described above in reference to FIG. 1. For example, an applicationprogram running on the user device 116 may generate voice or datainformation for transmission over the HFC network 110. This voice ordata information comprises the payload 615 of the data packet 605. Theapplication program running on the user device 116 will append the IPheader 609, the UDP header 611, and the RTP header 613 to the payload615 to allow for transmission in accordance with standard IP protocols.An Ethernet card within the user device 116 will further append the MACheader 607 to the data packet 605 to allow for transmission inaccordance with standard Ethernet protocols.

Upon receiving data packet 605, the cable modem suppresses the datapacket 605 in accordance with any desired header suppression technique.Examples of header suppression techniques include standard DOCSIS PHS,as well as techniques that extend beyond standard DOCSIS protocols, suchas Dynamic Delta Encoding and RTP Encoding, descriptions of which areprovided in further detail herein. After reading this specification, oneskilled in the relevant art(s) would recognize that any number ofsuppression techniques may be utilized without departing from the scopeof the present invention.

FIG. 6B represents the appearance of data packet 605 after beingcompressed to produce a compressed data packet 610 in accordance withembodiments of the present invention. In this exemplary embodiment, theIP header 609, the UPD header 611, and the RTP header 613 are eliminatedand replaced with a single byte index 617. Accordingly, the compresseddata packet 610 is comprised of Index 617, MAC header 607, and Payload615. The index 617 is comprised of one byte and is used to indicate thatdata packet 610 has been compressed. The index 617 is also used toindicate the particular suppression technique used to compress the datapacket. Further details of index 617 will be described below withrespect to FIG. 7. As a result of eliminating the above specifiedheaders, the compressed data packet 610 is 40 bytes smaller than theoriginal data packet 605.

FIG. 6C is an example of a mixed protocol DOCSIS transmit burst (i.e.,SID) 606 that contains multiple packets suppressed in accordance withembodiments of the present invention. The mixed protocol SID 606 iscomprised of the compressed data packet 610 and additional compresseddata packets 612 and 614. In one embodiment, compressed data packet 610is compressed using DOCSIS PHS as indicated by the index 617. Compresseddata packet 612 is compressed using Dynamic Delta encoding as indicatedby the index 619, and compressed data packet 614 is compressed using RTPencoding as indicated by the index 621. The indices 617, 619, and 621separate the packets within the mixed protocol SID 606. This separationis, in effect, a framing protocol. In this way, the mixed protocol SID606 is able to transmit multiple packets suppressed by different packetheader suppression techniques.

FIG. 7 depicts a flowchart 700 of a method for compressing packets usingdifferent packet header suppression techniques in accordance withembodiments of the present invention. The invention, however, is notlimited to the description provided herein with respect to flowchart700. Rather, it will be apparent to persons skilled in the relevantart(s) after reading the teachings provided herein that other functionalflows are within the scope and spirit of the present invention. Theflowchart 700 will be described with continued reference to the examplecable modem system 100 of FIG. 1.

At step 702, the cable modem 108 is turned on and initiates ahandshaking routine with the CMTS 104 via the HFC network 110. Duringthis initialization process, the cable modem 108 designates one or moreindex numbers to represent a particular type of packet headersuppression technique. For example, index 1 might be designated forDOCSIS PHS suppression, while index numbers 2 thru 10 might bedesignated for use with dynamic delta encoding. Still further, indexnumbers 11 thru 20 might be designated for use with RTP encoding. Oncethese designations are made, this information is communicated to theCMTS 104 via the HFC network 110. During the initialization process, therules associated with suppressing and expanding a packet in accordancewith the available suppression techniques are also exchanged. The rulesare provided to the CMTS 104 by the cable modem 108. The CMTS 104 storesthe index numbers and their corresponding rules in a lookup table forsubsequent retrieval during the packet expansion process.

In embodiments, the above-described initialization process is part ofstandard DOCSIS cable modem registration protocols. In alternateembodiments, a private communication channel previously described inreference to FIG. 4, above, may be used to facilitate the transfer ofindex numbers and rules. This may be particularly advantageous in DOCSIS1.0 cable modem systems in which the DOCSIS protocol does not define anyclassification/header suppression capability.

At step 704, the cable modem 108 receives a data packet from the userdevice 116. The data packet may be, for example, data packet 605 of FIG.6A.

At step 706, the cable modem 108 determines if the data packet should besuppressed in accordance with the present invention. In an embodiment,the cable modem 108 will not suppress the data packet if it is anuncompressible packet (i.e., not an IP packet). In this case, the cablemodem 108 would transmit the data packet with its full header.

At step 708, the cable modem 108 will select an appropriate packetheader suppression technique for those data packets identified in step706. In an embodiment, where data packets are of the unknown IP datagramtype, DOCSIS PHS is selected. For IP/RTP data packets (i.e., voicepackets), RTP suppression is selected. For IP/TCP variable length datapackets, Dynamic Delta suppression is selected.

At step 710, the cable modem 108 will append a packet header element tothe data packet being suppressed. The packet header element contains theindex number designated in step 702 for the particular suppressiontechnique selected in step 708.

At step 712, the data packet is suppressed in accordance with the rulesassociated with the suppression technique selected in step 708. Theresulting compressed data packet may be for example, the compressed datapacket 610 of FIG. 6B. In accordance with the present invention, thesteps (704-712 ) allow for the suppression of data packets in accordancewith any desired header suppression technique. The index numberassociated with each data packet identifies the beginning of the datapacket. Accordingly, the index number is a useful mechanism forseparating one data packet from another and identifying the particularheader suppression technique used to process each data packet.

As previously discussed, the DOCSIS protocol enables concatenation ofdata packets but, it does not allow the mixing of different headersuppression techniques within a single DOCSIS transmit burst or SID.However, because the index number contained in the packet header elementappended in step 710 provides a means for separating the packets, themixing of different header suppression techniques within a SID is nowpossible. Accordingly, in an alternative embodiment, a mixed protocolSID is produced in step 714.

In step 714, the data packets are concatenated with one another. As aresult of concatenating packets suppressed with different headersuppression techniques, the SID can now be viewed as a mixed protocolSID. In effect, the index serves as a framing protocol that separatesthe packets within the mixed protocol SID as well as communicates thetype of header suppression used on each data packet within the mixedprotocol SID. In an embodiment, the mixed protocol SID can be forexample, the mixed protocol SID 606 of FIG. 6C. Finally, in step 716,the mixed protocol SID is transmitted to a CMTS 104.

2. Packet Header Expansion

FIG. 8 is a flowchart of a method for expanding packets compressed usingdifferent packet header suppression techniques in accordance withembodiments of the present invention.

At step 802, the CMTS 104 receives a mixed protocol SID comprised of oneor more data packets.

At step 805, the CMTS 104 examines each of the data packets to determineif it has been suppressed. If a packet header element has been appendedto a data packet, then the CMTS 104 knows that the data packet has beensuppressed. If no packet header element is found, then the data packethas not been suppressed and controls passes immediately to step 820.

At step 810, the CMTS 104 searches its lookup table for the index numbercontained in the packet header element. If the index number is foundthen the expansion rules associated with the suppression technique havebeen previously provided to the CMTS 104. In an embodiment, theexpansion rules would have been previously provided during theinitialization process described in step 702. If the index number is notfound, then control passes to step 815.

At step 815, the CMTS 104 and the cable modem 108 exchange datadescribing the rules for expanding the data packet in real time (i.e.,as the data packet arrives).

At step 820, the CMTS 104 processes each of the data packets. In thecase where the data packet is not suppressed (i.e., a packet headerelement was not present) the data packet is processed according tostandard DOCSIS protocols. In the case where the data packet issuppressed (i.e., a packet header element was present) the CMTS 104retrieves the rules for expanding the data packet based upon thesuppression technique indicated by the index number found in the packetheader element. In expanding the data packet, CMTS 104 produces anuncompressed data packet. In an embodiment, at the end of step 820, CMTS104 would produce a data packet such as uncompressed data packet 605 ofFIG. 6A. Because the mixed protocol SID contains one or more datapackets, steps 805 thru 820 are repeated until all the data packetswithin the mixed protocol SID have been processed. Processing ends atstep 825.

3. RTP Header Suppression

As previously stated, the invention provides for Real-time TransportProtocol (RTP) header suppression. The RTP header suppression techniqueof the present invention provides great efficiency gains in networkbandwidth utilization by eliminating the transmission of redundantpatterns and by suppressing changing fields in a data stream. Theinvention accomplishes this by recognizing regular patterns in networktraffic. In embodiments, the regular patterns may be eliminated byhaving a sender of network traffic, such as CM 108, and a receiver ofnetwork traffic, such as CMTS 104, agree on the rules for proper headerreconstruction in order to reproduce the header at the receiving end. Byreducing the amount of network bandwidth needed to transmit RTPinformation across the network, the present invention enables increasedperformance for the same number of users on the network, as well as theability to efficiently add more users to the network.

Prior to describing the RTP header suppression technique of theinvention, a conventional 802.3/IP/UDP/RTP protocol header 900 for anRTP transmission will be described in FIG. 9A. Exemplary protocol header900 includes a 14-byte 802.3 header 902, a 20-byte IP (InternetProtocol) header 904, an 8-byte UDP (User Datagram Protocol) header 906,and a 12-byte RTP header 908. In this example, 802.3/IP/UDP/RTP header900 creates a 54-byte header. The data portion of an RTP packet may besmall in comparison to the overhead required to send the data using802.3/IP/UDP/RTP header 900. For example, the data portion of an RTPpacket may be as small as 20 bytes, resulting in less than half the sizeof header 900. Also, most of the fields within protocol header 900 donot change from packet to packet. The transmission of such redundantpatterns (non-changing header information from packet to packet) maywaste large amounts of network bandwidth, especially when the dataportion of the RTP packet is smaller than header 900. It would thereforebe very inefficient to transmit header 900 without compressing it.

DOCSIS 1.1 enables the suppression of redundant information in packetswith a feature called “payload header suppression” (PHS). PHS enablesthe suppression of unchanging bytes in an individual SID (i.e., datastream). Unfortunately, as previously stated, PHS cannot suppressdynamically changing fields.

The RTP header suppression technique of the present invention increasesthe efficiency of data delivery by recognizing patterns of behavior inthe changing fields of 802.3/IP/UDP/RTP header 900. FIG. 9B is a diagramof an RTP protocol packet 910. RTP protocol packet 910 comprises, interalia, a destination MAC address field 912, a source MAC address field914, a type/length field 916, a protocol version field 918, a headerlength field 920, a type of service field 922, a total length field 924,a packet ID field 926, a fragment offset field 928, a time to live field930, a protocol field 932, a header checksum field 934, a source IPaddress field 936, a destination IP address field 938, a source portfield 940, a destination port field 942, a length field 944, a checksumfield 946, a flag field 948, a sequence number field 950, a timestampfield 952, a synchronization source identifier field 954, a PDU 956, anda CRC-32 958. RTP protocol packets are well known in the relevantart(s), thus, each individual field will not be discussed in detail.

Most of header 900 may be suppressed. The fields of data packet 910 thatmay change from packet to packet include IP Packet ID field 926, IPHeader Checksum field 934, RTP sequence number field 950, and RTPtimestamp field 952. UDP checksum field 946 is always set to zerobecause it is not used. The remaining fields remain constant for thelife of a voice connection.

RTP sequence number field 950 starts at some arbitrary value andincrements by a value of one for each successive packet. RTP timestampfield 952 increments by a value based on the quantization interval ofthe codec. The second order delta of this number will always be zero forany given codec at a given quantization interval.

The invention enables the in-order deliver of packets on the upstreamDOCSIS RF link. The invention suppresses 802.3/IP/UDP/RTP header 900 onCM 108, and ensures that header 900 is recreated by CMTS 104. Thereconstruction of header 900 must be an exact reconstruction. This isaccomplished by calculating the difference between an RTP input packet'sRTP sequence number field 950 and the previous RTP packet's RTP sequencenumber field 950. When the difference between successive RTP packetsequence number fields 950 is 1, the difference between a new RTPpacket's timestamp field 952 and a previous RTP packet's timestamp field952 will be the first order difference, which will appear on everysuccessive packet while the codec and quantization interval remainconstant.

By observation, it was determined that the first order difference in RTPpacket timestamp field 952 is 80 decimal for a 10 millisecondquantization, for G711, G726, G738, and G729. For 5 millisecondquantization, the first order difference in RTP packet timestamp field952 is 40 decimal.

Initially, CM 108 sends one or more unsuppressed full headers with acontrol bit indicating that CMTS 104 is to “learn” header 900. Once thequantization value is determined, the quantization value is used toverify that the reconstruction of header 900 will be correct. At thattime, CM 108 sends either a “learn header” control bit with a fullheader in the event that reconstruction of header 900 may be incorrect,or a 5-bit RTP sequence delta, an 8-bit quantization value, and anoptional 1-byte IP packet ID delta in place of 54-byte 802.3/IP/UDP/RTPheader 900. In embodiments, during the learning process, more than onesequential header may be sent with the learn bit set. This ensures thatin the event a packet is dropped on the RF link, CMTS 104 will end upwith a valid template header from which to recreate packets once thelearn bit is no longer set.

FIG. 10 is a diagram illustrating a control value byte 1000 that is usedduring the operation of the RTP header suppression technique. Controlvalue byte 1000 comprises an L bit 1002, an I(1) bit 1004, an I(0) bit1006, and a 5-bit V value 1008. L bit 1002 is a learn bit. L bit 1002 isset when CMTS 104 is to learn header 900.

Modern IP protocol stacks often increment IP packet ID field 926 byeither 0x0001 or 0x0100 between datagrams. The present invention uses atwo-bit flag value, I(1) bit 1004 and I(0) bit 1006 to determine whetherto increment IP packet ID field 926 by 0x0001 or by 0x0100 or whether toreplace IP packet ID field 926 with a 2-byte delta field transmittedupstream by CM 108. If both I(1) and I(0) are not set, then IP packet IDfield 926 is incremented by 0x0001. If both I(1) and I(0) are set, thenIP packet ID field 926 is not incremented. If I(1) is not set and I(0)is set, then IP packet ID field 926 is incremented by 0x0100. If I(1) isset and I(0) is not set, then the change in IP packet ID field 926 istransmitted upstream in a two-byte delta field. Table 1 represents thefour possibilities for determining the value of IP packet ID field 926.TABLE 1 I(1) I(0) IP packet ID 0 0 increment by 0x0001 0 1 increment by0x0100 1 0 change is transmitted upstream in a two byte delta field 1 1no increment value

Control value (V) 1008 is a five bit value representing the delta valueof sequence number field 950.

FIG. 11 is a high level flow diagram 1100 illustrating a method for RTPheader suppression. The invention is not limited to the descriptionprovided herein with respect to flow diagram 1100. Rather, it will beapparent to persons skilled in the relevant art(s) after reading theteachings provided herein that other functional flow diagrams are withinthe scope of the present invention. The process begins with step 1102,where the process immediately proceeds to step 1104.

In step 1104, information concerning RTP header suppression iscommunicated from CM 108 to CMTS 104 to enable reconstruction of RTPpackets at CMTS 104. As previously discussed, this may include an indexnumber indicating the particular type of packet header suppressiontechnique, the rules associated with suppressing and reconstructing apacket in accordance with the particular type of packet headersuppression technique, etc. The process then proceeds to step 1106.

In step 1106, a complete RTP packet, such as RTP packet 910, is sent byCM 108 to CMTS 104 to enable CMTS 104 for learning. CMTS 104 stores thefull header of RTP packet 910 for future reference as a template. Theprocess then proceeds to decision step 1108.

In decision step 1108, it is determined whether CMTS 104 has learned RTPpacket 910. If CMTS 104 has not learned RTP packet 910, then the processreturns to step 1106, where a complete packet is sent from CM 108 toCMTS 104 for continued learning.

Returning to decision step 1108, if it is determined that CMTS 104 haslearned RTP packet 910, then the process proceeds to step 1110. In step1110, subsequent packets in the RTP stream are sent from CM 108 to CMTS104. The subsequent packets are comprised of delta values representingchanges in RTP header 900. Thus, the entire RTP packet 910 is no longersent. Instead, only delta values representing the changes in RTP header900 are sent. PDU field 956 is also sent. If error recovery is desired,the subsequent packets will also include an additional byte indicatingthe lower byte of RTP sequence number field 940. If a packet is droppedfor any reason, CMTS 104 may effectively re-synchronize the headerrestoration algorithm by applying the changes to sequence number field940 and timestamp field 952 of RTP header 900 for any missing packets.Thus, sending the lower order byte of packet sequence number field 940will enable reconstruction of dropped or lost packets. The process thenproceeds to decision step 1112.

In decision step 1112, it is determined whether all RTP packets havebeen sent. If all RTP packets have not been sent, the process returns todecision step 1110 for enabling subsequent packets in the RTP stream tobe sent to CMTS 104.

Returning to decision step 1112, if it is determined that all RTPpackets have been sent, then the process proceeds to step 11 14, wherethe process ends.

FIG. 12A is a flow diagram illustrating a method for suppressing an RTPheader using an RTP header suppression technique according to anembodiment of the present invention. The invention is not limited to thedescription provided herein with respect to flow diagram 1200. Rather,it will be apparent to persons skilled in the relevant art(s) afterreading the teachings provided herein that other functional flowdiagrams are within the scope of the present invention. The processbegins with step 1202, where an RTP suppressor is started at thetransmitting end (i.e., CM 108 ). The process immediately proceeds tostep 1204.

In step 1204, the delta of RTP timestamp field 952 between twoconsecutive RTP packets 900 is determined. The resultant value is thetimestamp delta value. The resultant timestamp delta value is set equalto temp(0). Note that during initialization, temp (0) is set to zero.The process then proceeds to step 1206.

In step 1206, the delta value for sequence number field 940 isdetermined. The resultant delta value is set equal to control value (V).This is accomplished by determining the low order byte of a new sequencenumber field 950 ANDed with the hex value 7 f and determining the loworder byte of the old sequence number field 950 ANDed with the hex value7 f. The resultant new sequence number field 950 value is thensubtracted from the resultant old sequence number field 950 to obtainthe delta or value of control value (V). The process then proceeds todecision step 1208.

In decision step 1208, it is determined whether proper reconstructionwill occur. This is accomplished by multiplying the delta value ofsequence number field 950, calculated in step 1206, by the constantvalue for the codec and adding it to the previous timestamp value. Ifthis value is not equal to the new timestamp, then the process proceedsto step 1210.

In step 1210, learn bit 1002 of control value 1000 is set. The processthen proceeds to step 1212.

In step 1212, temp(1) is set equal to control value 1000. Temp (1) nowcontains the delta value for sequence number field 950. The process thenproceeds to step 1214.

In step 1214, a new buffer is allocated and the two bytes from temp (thedelta value for timestamp field 952 and control value 1000, whichincludes the delta value for sequence number field 950 ) are stored inthe new buffer. The process proceeds to step 1216.

In step 1216, the new buffer and the original buffer, which contains acomplete RTP header 910, are transmitted to CMTS 104. Thus, the completeRTP header 910 along with the delta value for timestamp field 952 andcontrol value 1000 are sent to CMTS 104. The process then proceeds tostep 1218, where the process ends.

Returning to decision step 1208, if it is determined that the calculatedvalue is equal to the new timestamp field 952, then CM 108 hasdetermined the quantization value. The process proceeds to step 1220.

In step 1220, the increment value for incrementing IP packet ID field926 is determined. Bits I(1) 1004 and I(0) 1006 of control value 1000are set according to the value of the increment for the IP protocolstack being used. The control value is then stored in temp(1). Theprocess then proceeds to step 1222.

In step 1222, the two bytes from temp are copied to the original buffer.Temp (0) is the delta value for timestamp field 952 or the quantizationvalue. Temp (1) is control value 1000, which includes the delta valuefor sequence number field 950. The process then proceeds to step 1224.

In step 1224, the original length minus 52 bytes starting at offset 52is transmitted. Thus, the quantization value or the delta of timestampfield 952, control value 1000, and PDU field 956 are transmitted to CMTS104. The process then proceeds to step 1218, where the process ends.

As previously stated, modem IP protocol stacks commonly increment IPpacket ID field 926 by either 0x0001 or 0x01000 between datagrams. Aspecial rule in the present invention handles the setting of controlbits 1004 and 1006 to determine the increment value. FIG. 12B is a flowdiagram illustrating a method for setting increment bits I(1) 1004 andI(0) 1006 of control value 1000 for incrementing IP packet ID field 926in RTP packet 910. The process begins in step 1232, where the processimmediately proceeds to decision step 1234.

The present invention incorporates a test mode in which testing ofvarious aspects of the system may be done. When certain tests areperformed, control bits I(1) 1004 and I(0) 1006 are set accordingly toprovide an increment of zero. In decision step 1234, it is determinedwhether the system is in a test mode. If the system is in a test mode,then the process proceeds to step 1236.

In step 1236, control value bit I(1) 1004 is set to 1and control valuebit I(0) 1006 is set to 1. The process then proceeds to step 1248.

Returning to decision step 1234, if it is determined that the system isnot in a test mode, then the process proceeds to decision step 1238.

In decision step 1238, it is determined whether the value for IP packetID field 926 is to be sent upstream. If the value for IP packet ID field926 is to be sent upstream, the process will proceed to step 1240.

In step 1240, control value bit I(1) 1004 is set to 1 and control valuebit I(0) 1006 is set to 0. The process then proceeds to step 1248.

Returning to decision step 1238, if the value for IP packet ID field 926is not being sent upstream, the process proceeds to decision step 1242.

In decision step 1242, it is determined whether the IP protocol stackrequires an increment of 0x0001 for IP packet ID field 926. If the IPprotocol stack does require an increment of 0x0001 for IP packet IDfield 926, then the process proceeds to step 1244.

In step 1244, control value bit I(1) 1004 is set to 0 and control valuebit I(0) 1006 is set to 0. The process then proceeds to step 1248.

Returning to decision step 1242, if the IP protocol stack does notrequire an increment of 0x0001 for IP packet ID field 926, then theprocess proceeds to 1246.

In step 1246, an increment of 0x0100 is needed for IP packet ID field926. Control value bit I(1) 1004 is set to 0 and control value bit I(0)1006 is set to 1. The process then proceeds to step 1248.

In step 1248, the process ends.

FIG. 13 is a flow diagram 1300 illustrating a method for reconstructionof a suppressed RTP packet according to an embodiment of the presentinvention. The invention is not limited to the description providedherein with respect to flow diagram 1300. Rather, it will be apparent topersons skilled in the relevant art(s) after reading the teachingsprovided herein that other functional flow diagrams are within the scopeof the present invention. The process begins with step 1302, where thereconstructor is started. The process then proceeds to step 1304.

In step 1304, a 54-byte header is read. The process then proceeds tostep 1306.

In step 1306, 1-byte control value 1000 is read from the input stream.The process then proceeds to decision step 1308.

In decision step 1308, it is determined whether learn bit 1002 ofcontrol value 1000 is set. If it is determined that learn bit 1002 isset, then header 900 needs to be learned by CMTS 104. The process thenproceeds to step 1310.

In step 1310, a second 1-byte value is read from the input stream. Thissecond 1-byte value is discarded. The process then proceeds to step1312.

In step 1312, the current 54-byte header that was read in step 1304 isdiscarded. CMTS 104 discards this data because this 54-byte header wasgenerated by the hardware's payload header suppression mechanism at theend of the reconstructor process, which will be discussed below withreference to step 1318. When the hardware's payload header suppressionmechanism injects this 54-byte header, the 54-byte header is placedprior to control value 1000. Thus, when learn bit 1002 is set, this54-byte header is considered garbage and must be discarded. From thepoint of view of CM 108, what was sent was a suppression index. Receiptof the suppression index by CMTS 104 caused CMTS 104 to inject 54-bytesof incorrect data into the data stream. The process then proceeds tostep 1314.

In step 1314, the correct 54-byte header, transmitted from CM 108, isread from the input stream. The process then proceeds to step 1316.

In step 1316, the 54-byte header is copied to a template header and the54-byte header followed by the data from PDU 956 is emitted. The processthen proceeds to step 1318, where the process ends.

Returning to decision step 1308, if it is determined that learn bit 1002of control value 1000 is not set, then the process proceeds to step1320.

In step 1320, the second 1-byte value from the input stream is read andplaced into a low-order byte of a local variable named DELTA. DELTA is a32-bit long word. DELTA is pre-initialized to zero at the start of RTPdelta reconstructor process 1300. The process then proceeds to step1322.

Step 1322 begins the process for determining whether to increment IPpacket ID field 926 as set forth in Table 1. In step 1322, it isdetermined whether I(1) 1004 of control value 1000 is set. If I(1) 1004of control value 1000 is not set, then the process proceeds to step1324.

In step 1324, it is determined whether I(0) 1006 of control value 1000is set. If I(0) is not set, then the process proceeds to step 1326.

In step 1326, a local variable named INCR is set to 0x0001 forincrementing IP packet ID field 926. Note that local variable INCR is a16-bit unsigned value. INCR is pre-initialized to zero at step 1302. Theprocess then proceeds to step 1334.

Returning to step 1324, if I(0) is set, the process proceeds to step1328. In step 1328, local variable INCR is set to 0x0100 forincrementing IP packet ID field 926. The process then proceeds to step1334.

Returning to step 1322, if I(1) is set, the process proceeds to step1330. In step 1330, it is determined whether I(0) 1006 of control value1000 is set. If I(0) is set, then the process proceeds to step 1334.

Returning to step 1330, if I(0) is not set, then the process proceeds tostep 1332. In step 1332, the change in IP packet ID field 926 istransmitted upstream from CM 108. A two-byte unsigned value is read infrom the input stream and placed at offset 18 of the reconstructed datapacket. Offset 18 of the reconstructed data packet is IP packet ID field926. The process then proceeds to step 1334.

Steps 1334 through 1340 provide all of the updates to IP packet ID field926, RTP sequence number field 950, and RTP timestamp field 952 for thereconstruction of RTP packet 910. In step 1334, it is determined whetherthe bits 4-0 of the byte at offset 45 (low-order bits of sequence numberfield 950 ) of RTP packet 910 are equal to V 1008 in control value 1000.If it is determined that the bits 4-0 of the byte at offset 45(low-order bits of sequence number field 950 ) of RTP packet 910 areequal to V 1008 in control value 1000, then the process proceeds to step1342.

In step 1342, a new IP header checksum is determined and placed atoffset 24 (IP header checksum 934 ). IP header checksum field 934 is the16-bit one's complement of the one's complement sum of all 16-bit wordsin header 900. For purposes of computing the checksum, the value of thechecksum field is zero.

Returning to step 1334, if it is determined that the bits 4-0 of thebyte at offset 45 (low-order bits of sequence number field 950 ) of RTPpacket 910 are not equal to V 1008 in control value 1000, then theprocess proceeds to step 1336.

In step 1336, the value of one is added to the word at offset 44 of RTPpacket 910, which is RTP sequence number field 950. The process thenproceeds to step 1338.

In step 1338, the word at offset 18 of RTP packet 910, which is IPpacket ID field 926, is incremented by local variable INCR. The processthen proceeds to step 1340.

In step 1340, the word at offset 46 of RTP packet 910, which is RTPtimestamp field 952, is incremented by local variable DELTA. The processthen returns to step 1334, to determine if control value (V) 1008matches the five low-order bits in the sequence number field 950 of RTPpacket 910. Steps 1334 through 1340 will be repeated until these numbersare equal. When these numbers are equal, the process will proceed tostep 1342 as described above.

4. Dynamic Delta Encoding Scheme

As previously stated, the invention provides for optimizing thetransmission of TCP/IP (Internet Protocol) traffic across a DOCSISnetwork. The suppression technique of the present invention is fieldoriented rather than byte oriented. Many fields in a TCP protocol headerdo not change between packets in the same TCP connection stream. Thisredundant information is transmitted once, and suppressed in subsequentpackets. Other fields in the TCP protocol header change in a predictablemanner. These fields are not transmitted in their entirety. Instead, asmaller delta encoded value is transmitted that represents each field'schange in value from one packet to the next. The delta-encoded valuesfor 32-bit fields are always represented as a 16-bit number. Thistechnique reduces the bandwidth required to send the changing fields byapproximately 50%, and thus, provides a high efficiency gain in TCPAcknowledgement (ACK) transmission.

DOCSIS cable modems can ensure in-order delivery of packets on each IPstream. This guaranteed order of delivery enables the use of deltaencoded fields to update any changing fields in a 802.3/IP/TCP protocolheader.

Prior to describing the dynamic delta encoding scheme for TCP headersuppression, a conventional 802.3/IP/TCP protocol header 1400 for TCP/IPtransmission will be described in FIG. 14A. Protocol header 1400includes a 14-byte 802.3 header 1402, a 20-byte IP header 1404, and a20-byte TCP header 1406. In this example, 802.3/IP/TCP header 1400creates a 54-byte header for TCP/IP transmission.

FIG. 14B is a diagram of a TCP protocol packet 1410. TCP protocol packet1410 comprises, inter alia, a destination MAC address field 1412, asource MAC address field 1414, a type/length field 1416, a protocolversion field 1418, a header length field 1420, a type of service field1422, a total length field 1424, a packet ID field 1426, a fragmentoffset field 1428, a time to live field 1430, a protocol field 1432, aheader checksum field 1434, a source IP address field 1436, adestination IP address field 1438, a source port field 1440, adestination port field 1442, a sequence number field 1446, anacknowledgement number field 1448, a data offset field 1450, a flagsfield 1452, a window field 1454, a checksum field 1456, an urgentpointer field 1458, a PDU field 1460, and a CRC-32 field 1462. TCPprotocol packets are well known in the relevant art(s), thus, eachindividual field will not be discussed in detail.

Most of the fields in TCP protocol packet 1410 do not change betweenpackets in the same TCP connection stream. In TCP protocol packet 1410,all of header 1402 and most of header 1404 may be suppressed once thereceiver has learned the redundant or non-changing fields. Many of thefields in TCP header 1406 change between packets in the same TCPconnection stream. With the present invention, these fields are nottransmitted in their entirety. Instead, a smaller delta encoded value istransmitted. The delta encoded value represents each field's change invalue from one packet to the next.

FIG. 15 is a diagram illustrating the fields that change from packet topacket in TCP protocol packet 1410. The fields that change from packetto packet are highlighted. The changing fields include packet ID field1426 from IP header 1404, and sequence number field 1446,acknowledgement number field 1448, data offset field 1450, window field1454, checksum field 1456, and urgent pointer field 1458 from TCP header1406.

The invention enables the in-order delivery of packets on the upstreamDOCSIS RF link. The invention suppresses 802.3/IP/TCP header 1400 on CM108 and ensures that header 1400 is reconstructed to its original formatby CMTS 104. FIGS. 16A and 16B provide a high level description of thedelta-encoded suppression and reconstruction process, respectively, forthe present invention.

FIG. 16A is a high level flow diagram 1600 illustrating a method for adelta encoding suppression technique. The invention is not limited tothe description provided herein with respect to flow diagram 1600.Rather, it will be apparent to persons skilled in the relevant art(s)after reading the teachings provided herein that other functional flowdiagrams are within the scope of the present invention. The processbegins with step 1601, and immediately proceeds to step 1602.

In step 1602, information concerning TCP delta-encoded headersuppression is communicated from CM 108 to CMTS 104 to enablereconstruction of TCP packets at CMTS 104. As previously discussed, thismay include an index number indicating the particular type of packetheader suppression technique, the rules associated with suppressing andreconstructing a packet in accordance with the particular type of packetheader suppression technique, etc. CM 108 chooses the suppression index,and thus, the suppression technique. This prevents the need for atwo-way command transaction during fast data transfers. The process thenproceeds to step 1603.

In step 1603, an individual TCP connection stream is identified. Aframing protocol is used to separate and identify each TCP connectionstream on a single DOCSIS SID. After identifying the TCP connectionstream, the process proceeds to step 1604.

In step 1604, a first TCP protocol packet 1410 in a TCP connectionstream is transmitted to a receiver in its entirety. The first TCPprotocol packet 1410 includes a learn indicator. The indicator instructsthe receiver to learn the complete header. The complete protocol header1400 may be learned without requiring confirmation from a receiver, suchas CMTS 104. This allows headers to be learned in real-time. Once theheader has been learned, subsequent packets may be sent in a compressedformat. Maximum efficiency is achieved by permitting an unsuppressed(learned) header to be immediately followed by a suppressed header. Thiseliminates the delay introduced in the DOCSIS approach which requireswaiting for a learned acknowledgment from the receiver. The process thenproceeds to step 1606.

In step 1606, the next packet in the TCP connection stream is retrieved.The process then proceeds to step 1608.

In step 1608, the fields that have changed from the previous transmittedpacket are identified and a delta encoded value representing that changeis determined. The process then proceeds to step 1610.

In step 1610, a bit-mapped flag is generated. The bit-mapped flagindicates which of the possible delta encoded IP/TCP field values arepresent between a change byte and the compressed TCP protocol packet'sdata area. The change byte is a one-byte bitmapped flag field forindicating which fields within protocol header 1400 have changed. Thechange byte will be discussed in more detail below with reference toFIG. 17. The process then proceeds to step 1612.

In step 1612, the compressed TCP protocol packet is generated and thebit-mapped flag is appended to the front of the compressed TCP packet.The process then proceeds to step 1614.

In step 1614, the compressed TCP protocol packet is transmitted to thereceiver. The process then proceeds to decision step 1616.

In decision step 1616, it is determined whether there are more TCPprotocol packets 1410 in the TCP connection stream to be transmitted. Ifthere are more packets to be transmitted, then the process returns tostep 1606 to retrieve the next packet.

Returning to decision step 1616, if there are no more packets to betransmitted in the TCP connection stream, the process will proceed backto step 1603, where another TCP connection stream is identified.

FIG. 16B is a high level flow diagram 1620 illustrating a method for adelta encoded header reconstruction technique. The invention is notlimited to the description provided herein with respect to flow diagram1620. Rather, it will be apparent to persons skilled in the relevantart(s) after reading the teachings provided herein that other functionalflow diagrams are within the scope of the present invention. The processbegins with step 1622, where the process immediately proceeds to step1624.

In step 1624, a TCP protocol packet 1410 from a TCP connection stream isretrieved. The process then proceeds to decision step 1626.

In decision step 1626, it is determined whether the retrieved TCPprotocol packet 1410 is to be learned. This is accomplished bydetermining whether the indicator learn bit is set. If the indicatorlearn bit is set, the process proceeds to step 1628.

In step 1628, the receiver learns the current TCP protocol header ofpacket 1410, and stores packet 1410 for future reference as a headertemplate. The process then returns to step 1624 to retrieve anotherpacket.

Returning to decision step 1626, if the indicator learn bit is not set,the process proceeds to step 1630.

In step 1630, the change byte is read and the correspondingdelta-encoded values are read. The process then proceeds to step 1632.

In step 1632, the header is reconstructed. The TCP/IP header flags areupdated and the delta-encoded values are used to update the changedfields in a stored header template. The process then proceeds to step1634.

In step 1634, the completely restored header is placed in front of anyreceived data from the TCP protocol packet retrieved in step 1624. Atthis point, the packet is completely restored to its original format,and can be transmitted over an IP network. The process then proceedsback to step 1624, where another TCP protocol packet is retrieved.

FIG. 17 is a diagram illustrating the change byte 1700 that is used inexecuting the delta-encoded header suppression technique. Change byte1700 is a 1-byte bitmapped flag field for indicating which fields ofprotocol header 1400 have changed. Change byte 1700 also indicateswhether or not header 1400 is to be learned at the receiving end. Changebyte 1700 further indicates whether to increment IP packet ID 1426 andthe amount by which IP packet ID 1426 should be incremented. Change byte1700 comprises an L bit 1702, an I(1) bit 1704, an I(0) bit 1706, an Sbit 1708, an A bit 1710, a P bit 1712, a W bit 1714, and a U bit 1716.

L bit 1702, when set, indicates that the remainder of the change bytecan be ignored and that an entire 54-byte 802.3/IP/TCP header 1400 isincluded in the burst and should be used to replace the current templateheader.

I(1) bit 1704 and I(0) bit 1706 are used to determine the change for IPpacket ID field 1426 in a similar manner as indicated in Table 1 above.I(1) bit 1704, when set, indicates that the next value in the datastream is a 2-byte value to be copied to IP packet ID field 1426 of thetemplate header. The result should be written back to the templateheader and emitted. When I(1) bit 1704 is clear, I(0) bit 1706, must bechecked to determine how to increment IP packet ID 1426. I(0) bit 1706,when set, indicates that 0x0100 should be added to the template headerIP packet ID field 1426, written back to the template header, andemitted. When clear, I(0) bit 1706 indicates that the template header IPpacket ID field 1426 should be incremented by 0x0001, written back tothe template header, and emitted. I(1) bit 1704 and I(0) bit 1706 aredetermined based upon the operation of modern IP protocol stacks and themanner in which they are incremented as described above.

S bit 1708, when set, indicates that the next value in the data streamis a 2-byte value to be added to the 4-byte TCP sequence number field1446 of the template header. The result should be written back to thetemplate header and emitted. When S bit 1708 is clear, TCP sequencenumber field 1446 of the template header should be used as is.

When A bit 1710 is set, the next value in the data stream is a 2-bytevalue to be added to the 4-byte TCP acknowledgement number field 1448 ofthe template header. The result should be written back to the templateheader and emitted. When A bit 1710 is clear, TCP acknowledgement numberfield 1448 of the template header should be used as is.

P bit 1712, when set, indicates that the PUSH bit (not shown) of anibble of TCP flags field 1452 should be set and emitted. When P bit1712 is clear, the PUSH bit of a nibble of TCP flags field 1452 shouldbe cleared and emitted.

When W bit 1714 is set, the next value in the data stream is a 2-bytevalue to be copied to TCP window field 1454 of the template header. Theresult should be written back to the template header and emitted. When Wbit 1714 is clear, TCP window field 1454 of the template header shouldbe used as is.

When U bit 1716 is set, the next value in the data stream is a 2-bytevalue to be copied to TCP urgent pointer field 1458 of the templateheader. The result should be written back to the template header andemitted. When U bit 1716 is clear, TCP urgent pointer field 1458 of thetemplate header should be used as is.

Based on the fields that actually change from the previous transmittedvalues, one of two actions will occur. TCP protocol packet 1410 may besent without any suppression whatsoever or TCP protocol packet 1410 maybe appended to change byte 1700 and include either an entire TCPprotocol packet 1410 or two or more fields in place of 54-byte802.3/IP/TCP header 1400. The two or more fields that replace802.3/IP/TCP header 1400 include: (1) an actual IP packet ID 1426 value(which is sent only if IP packet ID did not increment by 0x0001 or0x0100); (2) a delta-encoded value for TCP sequence number 1446 (whichis sent only if the delta-encoded TCP sequence number ≠ 0); (3) adelta-encoded value for TCP acknowledgement number field 1448 (which issent only if the delta-encoded TCP acknowledgement number ≠0); (4) abyte of data for TCP data offset field 1450; (5) an actual value for TCPwindow field 1454 (which is sent only if a delta value for TCP windowfield 1454 ≠0); (6) an actual value for TCP header checksum field 1456;and (7) an actual value for TCP urgent pointer field 1458 (which is sentonly if IP urgent flag is set). The invention, therefore, uses a framingmechanism that combines compressed, uncompressed, and non-IP styletraffic on a single DOCSIS SID.

Traditional Internet TCP/IP header suppression protocols use a variablelength delta encoding scheme to represent changing fields. The presenttechnique is optimized for characteristics of high-speed TCP/IPnetworks. For such networks, the changing TCP fields (i.e., ACK, SEQ,WIN) typically increment by more than 255 units. Encoding these changeswith a fixed, two-byte delta field optimizes the typical case forhigh-speed networks, and reduces the processing required for eachtransmitted TCP protocol packet 1410.

FIG. 18 is a diagram illustrating a final encoded data stream 1800 thatis sent to a receiver (i.e., CMTS) when L bit 1702 is not set. FIG. 18shows a first row 1802 for each field in final encoded data stream 1800and a second row 1804 indicating a number of bytes that correspond toeach field in final encoded data stream 1800.

A first field 1806 is change byte 1700. As previously indicated, changebyte 1700 is comprised of 1-byte 1806.

A second field 1808 is a delta-encoded value for IP packet ID field1426. Delta-encoded value 1808 for IP packet ID field 1426 may consistof either 0 or 2-bytes of data (1809), depending upon whether a value isto be copied into the template header for IP packet ID field 1426 or ifthe value of IP packet ID field 1426 is to be incremented by either0x0001 or 0x0100. If a value is to be copied into the template headerfor IP packet ID field 1426, then final encoded data stream 1800 willcontain 2-bytes for IP packet ID field 1426. If a value is not to becopied into the template header for IP packet ID field 1426, then finalencoded data stream 1800 will not contain any bytes for IP packet ID1426. Instead, an increment value for IP packet ID field 1426 will bedetermined using bits I(1) 1704 and I(0) 1706 of change byte 1700.

A third field 1810 is a delta-encoded value for TCP sequence number1446. Delta-encoded value 1810 for TCP sequence number field 1446 mayconsist of either 0 or 2-bytes of data (1811 ), depending upon whether achange occurred in TCP sequence number field 1446 from the previoustransmitted value. If a change occurred in TCP sequence number 1446 fromthe previous transmitted value, S bit 1708 of change byte 1700 will beset and final encoded data stream 1800 will contain 2-bytes of data forupdating TCP sequence number field 1446 in the template header. If achange did not occur in TCP sequence number field 1446 from the previoustransmitted value, S bit 1708 of change byte 1700 will not be set andfinal encoded data stream 1800 will not contain any bytes for TCPsequence number field 1446.

A fourth field 1812 is a delta-encoded value for TCP acknowledgementnumber field 1448. Delta-encoded value 1812 for TCP acknowledgementnumber field 1448 may consist of either 0 or 2-bytes of data (1813 ),depending upon whether a change occurred in TCP acknowledgement numberfield 1448 from the previous transmitted value. If a change occurred inTCP acknowledgement number field 1448 from the previous transmittedvalue, A bit 1710 of change byte 1700 will be set and final encoded datastream 1800 will contain 2-bytes of data for updating TCPacknowledgement number field 1448 in the template header. If a changedid not occur in sequence number field 1446 from the previoustransmitted value, A bit 1710 of change byte 1700 will not be set andfinal encoded data stream 1800 will not contain any bytes for TCPacknowledgement number field 1448.

A fifth field 1814 is for TCP data offset field 1450. A value for TCPdata offset field 1450 consists of 1-byte of data (1815 ) to be insertedin final encoded data stream 1800.

A sixth field 1816 is for TCP window field 1454. A value for TCP windowfield 1454 may consist of 0 or 2-bytes of data (1817 ), depending uponwhether a change occurred in TCP window field 1454 from the previoustransmitted value. If a change occurred in TCP window field 1454 fromthe previous transmitted value, W bit 1714 of change byte 1700 will beset and final encoded data stream 1800 will contain 2-bytes of data forupdating TCP window field 1454 in the template header. If a change didnot occur in TCP window field 1454 from the previous transmitted value,W bit 1714 of change byte 1700 will not be set and final encoded datastream 1800 will not contain any bytes for TCP window field 1454.

A seventh field 1818 is for TCP checksum field 1456. A value for TCPchecksum field 1456 consists of 2-bytes of data (1819 ) to be insertedin final encoded data stream 1800.

An eighth field 1820 is for TCP urgent pointer field 1458. A value forTCP urgent pointer field 1458 may consist of 0 or 2-bytes of data (1821), depending upon whether an IP urgent flag in TCP flags field 1452 isset. If the IP urgent flag in TCP flags field 1452 is set, U bit 1716 ofchange byte 1700 will be set and final encoded data stream 1800 willcontain 2-bytes of data to be copied into the template header. If the IPurgent flag in TCP flags field 1452 is not set, U bit 1716 of changebyte 1700 will not be set and final encoded data stream 1800 will notcontain any bytes for TCP urgent pointer field 1458.

A ninth field 1822 is for TCP PDU 1460. TCP PDU may consist of 0-n bytes(1823 ).

FIG. 19 is a diagram illustrating a transmit order 1900 for finalencoded data stream 1800 when L bit 1702 is not set. Transmit order 1900begins with change byte 1700. Fields 1808, 1810, 1812, 1814, 1816, 1818,1820, and 1822 follow.

FIG. 20 is a diagram illustrating a transmit order 2000 when L bit 1702is set. This indicates that the header information being transmitted isto be learned by the receiver. Transmit order 2000 consists of changebyte 1700, a pad 2002, 54-byte TCP protocol header 1410, and PDU 1460.

FIG. 21 is a flow diagram 2100 illustrating a method for TCP headersuppression. The invention is not limited to the description providedherein with respect to flow diagram 2100. Rather, it will be apparent topersons skilled in the relevant art(s) after reading the teachingsprovided herein that other fictional flow diagrams are within the scopeof the present invention. The process begins with step 2102, where a TCPsuppressor is started. The process then proceeds to step 2104.

In step 2104, L bit 1702, I(1) bit 1704, I(0) bit 1706, S bit 1708, Abit 1710, P bit 1712, W bit 1714, and U bit 1716 of change byte 1700 aredetermined. The change byte is then copied to temp(0 ). The process thenproceeds to decision step 2106.

In decision step 2106, it is determined whether L bit 1702 is set. If Lbit 1702 is set, this indicates that 802.3/IP/TCP should be sent in itsentirety to be learned by a receiver, such as CMTS 104. The process thenproceeds to step 2108.

In step 2108, a new buffer is allocated. The process then proceeds tostep 2110.

In step 2110, change byte 1700 and a single pad byte are stored in thebuffer allocated in step 2108. The system hardware does not like to seebuffers with an allocation of a single byte. Thus a hardware constraintis to provide buffers with more than 1-byte. Thus, a pad byte is alsoinserted into the buffer. The process then proceeds to step 2112.

In step 2112, an original buffer which holds TCP protocol packet 1410 isappended to the new buffer on a BD ring. The process then proceeds tostep 2114.

In step 2114, the original buffer length and the new buffer length aretransmitted. Thus, the change byte and a pad are transmitted with the54-byte header and PDU 1460 for learning the complete 802.3/IP/TCPheader 1400. When L bit 1702 is set, transmit order 2000 applies. Theprocess then proceeds to step 2116, where the process ends.

Returning to decision step 2106, if L bit 1702 is not set, the processthen proceeds to step 2118. In step 2118, the length of temp iscalculated, and a pointer is set to buffer [54] minus the length oftemp. The length of temp includes the length of all of the data beingsent in final encoded data stream 1800. The process then proceeds tostep 2120.

In step 2120, temp is copied to the pointer. The process then proceedsto step 2122.

In step 2122, the pointer is put on the BD ring. The process thenproceeds to step 2124.

In step 2124, the original length−[54]+length of temp is transmitted.Thus, final encoded data stream 1800 is transmitted. When L bit 1702 isnot set, transmit order 1900 applies. The process then proceeds to step2116, where the process ends.

FIGS. 22A and 22 B are a flow diagram 2200 illustrating a method for TCPheader reconstruction. The invention is not limited to the descriptionprovided herein with respect to flow diagram 2200. Rather, it will beapparent to persons skilled in the relevant art(s) after reading theteachings provided herein that other functional flow diagrams are withinthe scope of the present invention. A 54-byte template header isgenerated by the DOCSIS payload header reconstruction engine (not shown)prior to the start of flow diagram 2200. The process begins with step2202 in FIG. 22A, where a TCP header reconstructor is started. Theprocess then proceeds to step 2204.

In step 2204, a 54-byte header is read from the input stream. Theprocess then proceeds to step 2206.

In step 2206, change byte 1700 is read from the input stream. Theprocess then proceeds to decision step 2208.

In decision step 2208, it is determined whether L bit 1702 from changebyte 1700 is set. If L bit 1702 is set, then the process proceeds tostep 2210.

In step 2210, the 54-byte header that was captured in step 2204 isdiscarded. This data is discarded because this data was not generatedfrom the input stream, but was generated from the hardware's payloadheader suppression mechanism at the end of the reconstructor process,which will be discussed below with reference to step 2216. When thehardware's payload header suppression mechanism injects this 54-byteheader, the 54-byte header is placed prior to change byte 1700. Thus,when L bit 1702 is set, this 54-byte header is considered garbage andmust be discarded. From the point of view of CM 108, what was sent was asuppression index. Receipt of the suppression index by CMTS 104 causedCMTS 104 to inject 54-bytes of incorrect data into the data stream. Theprocess then proceeds to step 2212.

In step 2212, a 1-byte pad is read from the input stream and discarded.The process then proceeds to step 2214.

In step 2214, the correct 54-byte header, transmitted from CM 108, isread from the input stream. The process then proceeds to step 2216 inFIG. 22B.

In step 2216, the correct 54-byte header is copied to a template headerand the 54-byte header and the data from PDU 1460 that follows isemitted. The process then proceeds to step 2218, where the process ends.

Returning to decision step 2208 in FIG. 22A, if L bit 1702 of changebyte 1700 is not set, then the process proceeds to decision step 2220.

Decision step 2220 begins the process for determining whether toincrement IP packet ID field 1426 by 0x0001 or 0x0100 or to copy a2-byte value from the input stream into the template header of IP packetID field 1426. In decision step 2220, it is determined whether I(1) bit1704 of change byte 1700 is set. If I(1) is set, the process proceeds tostep 2222.

In step 2222, a 2-byte value is read from the input stream and copiedinto IP packet ID field 1426 (offset 18). The process then proceeds tostep 2230.

Returning to decision step 2220, if I(1) bit 1704 of change byte 1700 isnot set, the process proceeds to decision step 2224. In decision step2224, it is determined whether I(0) bit 1706 of change byte 1700 is set.If I(0) bit 1706 is not set, the process proceeds to step 2226.

In step 2226, 0x0001 is added to IP packet ID 1426 at offset 18. Theprocess then proceeds to step 2230.

Returning to decision step 2224, if I(0) bit 1706 of change byte 1700 isset, the process proceeds to step 2228. In step 2228, 0x0100 is added toIP packet ID 1426 at offset 18. The process then proceeds to decisionstep 2230.

In decision step 2230, it is determined whether S bit 1708 of changebyte 1700 is set. If S bit 1708 is set, indicating that a change hasoccurred in TCP sequence number field 1446 from the previous value, theprocess proceeds to step 2232.

In step 2232, the next 2-bytes of data from the input data stream areadded to TCP sequence number field 1446 at offset 38. The process thenproceeds to decision step 2234.

Returning to decision step 2230, if S bit 1708 of change byte 1700 isnot set, the process proceeds to decision step 2234.

In decision step 2234, it is determined whether A bit 1710 of changebyte 1700 is set. If A bit 1710 is set, indicating that a change hasoccurred in TCP acknowledgement number field 1448, then the processproceeds to step 2236.

In step 2236, the next 2-bytes of data from the input stream are addedto TCP acknowledgement number field 1448 at offset 42. The process thenproceeds to step 2238.

Returning to decision step 2234, if A bit 1710 of change byte 1700 isnot set, then the process proceeds to step 2238.

In step 2238, the next byte of data from the input stream is copied intoTCP data offset field 1450 at offset 46. The process proceeds todecision step 2240.

In decision step 2240, it is determined whether P bit 1712 of changebyte 1700 is set. If P bit 1712 is set, the process proceeds to step2242.

In step 2242, 0x08 is ORed with the data in TCP flag field 1452 atoffset 47. The process proceeds to decision step 2246.

Returning to decision step 2240, if P bit 1712 of change byte 1700 isnot set, the process proceeds to step 2244.

In step 2244, 0xF7 is ANDed with the data in TCP flag field 1452 atoffset 47. The process proceeds to decision step 2246.

In decision step 2246, it is determined whether W bit 1714 of changebyte 1700 is set. If W bit 1714 is set, indicating that a change hasoccurred in TCP window field 1454, the process proceeds to step 2248.

In step 2248, the next 2-bytes of data from the input stream are copiedinto TCP window field 1454 at offset 48. The process then proceeds tostep 2250.

Returning to decision step 2246, if it is determined that W bit 1714 ofchange byte 1700 is not set, the process proceeds to step 2250.

In step 2250, the next 2-bytes of data from the input stream are copiedinto TCP checksum field 1456 at offset 50. The process then proceeds todecision step 2252 in FIG. 22B.

In decision step 2252, it is determined whether U bit 1716 of changebyte 1700 is set. If U bit 1716 is set, the process proceeds to step2254.

In step 2254, the next 2-bytes of data from the input stream are copiedinto TCP urgent pointer field 1458 at offset 52. The process thenproceeds to step 2256.

In step 2256, the U bit in TCP flags field 1452 is set by Oring 0x20 toTCP flags field 1452 at offset 47. The process then proceeds to step2260.

Returning to decision step 2252, if U bit 1716 of change byte 1700 isnot set, then the process proceeds to step 2258. In step 2258, the U bitin TCP flags field 1452 is cleared by ANDing 0xDF to TCP flags field1452 at offset 47. The process then proceeds to step 2260.

In step 2260, IP total length field 1424 is set equal to the remainingPDU 1460 length plus 40 bytes. A new IP header checksum field 1434 isdetermined and placed in the template header at offset 24. IP headerchecksum is the 16-bit one's complement of the one's complement sum ofthe values at offsets 14, 16, 18, 22, 26, 28, 30, and 32. The processthen proceeds to step 2216, where 54-bytes are copied to the templateheader and emitted. The process then proceeds to step 2218, where theprocess ends.

D. Environment

As discussed elsewhere herein, the above-described techniques or methodsmay be executed as software routines, in part, by the MAC portion of acable modem and the headend MAC portion of a CMTS. For example, withreference to the example implementation of cable modem 108 described inreference to FIG. 3, MAC 314 performs necessary method steps byexecuting software functions with the assistance of CPU 320. Thesesoftware functions may be stored in either RAM 322 or ROM 324.Furthermore, with reference to the example implementation of CMTS 104,headend MAC 218 performs necessary method steps by executing softwarefunctions with the assistance of CPU 222. These software functions maybe stored in either RAM 220 or ROM 218.

However, methods of the present invention need not be limited to theseembodiments. For example, the methods of the present invention may beembodied in software routines which are executed on computer systems,such as a computer system 2300 as shown in FIG. 23. Various embodimentsare described in terms of this exemplary computer system 2300. Afterreading this description, it will be apparent to a person skilled in therelevant art how to implement the invention using other computer systemsand/or computer architectures. The computer system 2300 includes one ormore processors, such as processor 2303. The processor 2303 is connectedto a communication bus 2302.

Computer system 2300 also includes a main memory 2305, preferably randomaccess memory (RAM), and may also include a secondary memory 2310. Thesecondary memory 2310 may include, for example, a hard disk drive 2312and/or a removable storage drive 2314, representing a floppy disk drive,a magnetic tape drive, an optical disk drive, etc. The removable storagedrive 2314 reads from and/or writes to a removable storage unit 2318 ina well-known manner. Removable storage unit 2318, represents a floppydisk, magnetic tape, optical disk, etc., which is read by and written toby removable storage drive 2314. As will be appreciated, the removablestorage unit 2318 includes a computer usable storage medium havingstored therein computer software and/or data.

In alternative embodiments, secondary memory 2310 may include othersimilar means for allowing computer programs or other instructions to beloaded into computer system 2300. Such means may include, for example, aremovable storage unit 2322 and an interface 2320. Examples of such mayinclude a program cartridge and cartridge interface (such as that foundin video game devices), a removable memory chip (such as an EPROM, orPROM) and associated socket, and other removable storage units 2322 andinterfaces 2320 which allow software and data to be transferred from theremovable storage unit 2322 to computer system 2300.

Computer system 2300 may also include a communications interface 2324.Communications interface 2324 allows software and data to be transferredbetween computer system 2300 and external devices. Examples ofcommunications interface 2324 may include a modem, a network interface(such as an Ethernet card), a communications port, a PCMCIA slot andcard, a wireless LAN (local area network) interface, etc. Software anddata transferred via communications interface 2324 are in the form ofsignals 2328 which may be electronic, electromagnetic, optical, or othersignals capable of being received by communications interface 2324.These signals 2328 are provided to communications interface 2324 via acommunications path (i.e., channel) 2326. This channel 2326 carriessignals 2328 and may be implemented using wire or cable, fiber optics, aphone line, a cellular phone link, a wireless link, and othercommunications channels.

In this document, the term “computer program product” refers toremovable storage units 2318, 2322, and signals 2328. These computerprogram products are means for providing software to computer system2300. The invention is directed to such computer program products.

Computer programs (also called computer control logic) are stored inmain memory 2305, and/or secondary memory 2310 and/or in computerprogram products. Computer programs may also be received viacommunications interface 2324. Such computer programs, when executed,enable the computer system 2300 to perform the features of the presentinvention as discussed herein. In particular, the computer programs,when executed, enable the processor 2303 to perform the features of thepresent invention. Accordingly, such computer programs representcontrollers of the computer system 2300.

In an embodiment where the invention is implemented using software, thesoftware may be stored in a computer program product and loaded intocomputer system 2300 using removable storage drive 2314, hard drive 2312or communications interface 2324. The control logic (software), whenexecuted by the processor 2303, causes the processor 2303 to perform thefunctions of the invention as described herein.

In another embodiment, the invention is implemented primarily inhardware using, for example, hardware components such as applicationspecific integrated circuits (ASICs). Implementation of hardware statemachine(s) so as to perform the functions described herein will beapparent to persons skilled in the relevant art(s).

In yet another embodiment, the invention is implemented using acombination of both hardware and software.

E. Conclusion

The present invention is not limited to the embodiment of a cable modemsystem. The present invention can be used with any system that transmitsRTP packets over a network. The previous description of the preferredembodiments is provided to enable any person skilled in the art to makeor use the present invention. While the invention has been particularlyshown and described with reference to preferred embodiments thereof, itwill be understood by those skilled in the art that various changes inform and detail may be made therein without departing from the spiritand scope of the invention.

1. A method for RTP header suppression in a cable modem system,comprising the steps of: (a) sending an index number to a receiver,wherein said index number represents an RTP header suppressiontechnique; (b) sending rules associated with said RTP header suppressiontechnique; (c) transmitting at least one complete RTP packet; (d)transmitting subsequent RTP packets in an RTP stream, wherein saidsubsequent RTP packets are comprised of delta values representing fieldsthat dynamically change from packet to packet in an RTP data packet.2-22. (canceled)